【レポート】The evolution of chaos engineering at Netflix #NFX303 #reinvent

はじめに

こんにちは、かみとです。
re:Inventに現地参加しました。
本レポートは現地で参加したものを後日まとめたものです。
Netflixのカオスエンジニアリングの話があるということで自分的にこの日のメインディッシュと定めていたのですが、会場を間違えてしまいました。
私が行ったのはContents Hub会場といって、セッションのあるメイン会場ではなく、メイン会場に入れなかった人たちがストリーミングで見る用の会場でした。。
まあ見れたのでよしとします。

セッション概要

Chaos engineering was born at Netflix a decade ago, and views on this discipline have shifted and evolved over time. In this session, hear how chaos engineering has grown into the discipline of infrastructure experimentation. Learn how Netflix is using this approach and what is needed to unlock this technology in your organization.

カオスエンジニアリングは10年前にNetflixで生まれ、この学問に対する見方は時代とともに変化し、進化してきました。このセッションでは、カオスエンジニアリングがどのようにインフラストラクチャの実験という学問に成長したかを聞きます。このセッションでは、Netflix がどのようにこのアプローチを使用しているか、また、あなたの組織でこの技術を解放するために何が必要かを学びます。

• Speaker : Aleš Plšek - Senior Software Engineer
• Session type : Breakout Session
• Session level : 300 - Advanced

セッション内容

• カオスエンジニアリングがNetflixで誕生して１０年以上が経つ
• 今日話すことは以下
  • Netflixにおけるカオスエンジニアリングの歴史について話したい
    • 私達が経験したターニングポイントや長年にわたって築いてきたテクノロジーについて
  • カオスエンジニアリングという学問に対する私達の考え方が、この数年の間にどのように進化してきたか。
  • カオスエンジニアリングが当初の目的や範囲を超えてどのように成長し、当社のあらゆるソフトウェアエンジニアの生活にどのような影響を与えているか

Netflixのカオスエンジニアリングの歴史

• Netflixの体験は大きく２つの大きな技術によって構成されている
  • 一つは小さなインスタンスで構成されるクラウド
  • もう一つはNetflixが所有するオープンコネクトCDN
• あなたがNetflixのビデオの再生ボタンをクリックするとストリームが開始されるが、その数をSPS（Start Per Second）と呼んでいて、私達が重要な指標としてモニターしている
• SPSが日々どのように変化しているかをモニタリングしつつ、その数値は受け入れるべきものとしている。
• これは一種のライフサイクルで、例えば小さなインスタンスがダウンした場合でも、ストリーミング体験に影響が出ないようにする必要がある

Chaos Monkey

• そのため、私達はChaos Monkeyを構築した
• Chaos Monkeyは、個々のノードの障害に対するストリーミングインフラの回復力をテストするために使われた
• このツールは、データセンター内のインスタンスをいくつかランダムに選び、あらかじめ設定されたスケジュールでシャットダウンを開始する
• これは非常に効果的なアプローチだった
• そのため、ノードがダウンしたとしても復旧できる、レジリエンスのあるサービスを提供することができた
• これはカオスエンジニアリングの代名詞となっている
• しかし、ツールの利用は減少している
  • 私達のバックエンドアーキテクチャが単純なインスタンスのセットよりもずっと複雑なことが理由
  • 個々のノードだけでなく、アーキテクチャ全体を考慮したより回復力のあるものにしたいと考えた

2014年の障害

• さらに、2014年にはNetflixが障害を起こし、加入者情報の管理を担当するサービスに内部エラーが発生した
  • 会社のビジネスにとって非常に重要
  • 通常であれば、加入者を管理する機能はプロフィールを変更したりなどが主な機能で、ストリーミング体験には影響しないものだったのだが、この障害ではストリーミング再生をすることができなかったのが最大の問題だった
  • フォールバックが適切に行われているかどうかのテストができていなかった
• ストリーミングアーキテクチャでは、クリティカルでないサービスの障害に対する耐障害性が低かった、そのためにこの障害が発生したと言える

Nerflixのカオスエンジニアリングの進化

• この問題から、このようなシナリオをシミュレートし、サービス自体に障害を注入できるようにする必要性があることを学んだ

FIT（Failure Injection Technology）

• そこで開発されたのがFIT（Failure Injection Technology）
• 障害注入の精度を高めることを可能にした
  • つまり、インフラ内のどのようなサービスに対してもFITによってインジェクション・ポイントを定義可能
  • 例えば、gRPCやREST API、GraphQLと他のサービスとの通信を行う場合、IPCライブラリにインジェクションポイントを用意している
  • サーバー側でもクライアント側でも通信に障害を注入することができる
  • データベースライブラリのインジェクションポイントでは、Cassandraインスタンスから特定のデータポイントを取得しようとする呼び出しに対して障害を注入することが可能
• また、FITではそのインジェクションポイントに注入したいTreatment(治療法)を定義することができる
  • Treatmentはインジェクションポイントによって設定され、多くの異なるタイプにすることができる
  • また、これを使うことでインジェクションポイントに対してまずはリクエストを遅延させ、次にそれを失敗させる、ということが可能
• 次にスコープを定義することができる
  • スコープは、どのインジェクションポイントがトリガーされるのかを定義するのに使われる
  • これによりクラスタごとにスコープを定義することができる
  • しかし、これではまだ人により手動での監視が必要となり、多くの時間と労力が必要
• そこでスコープ能力をさらに向上させるため、リクエストコンテキストテクノロジー（我々はCRRと呼んでいますが）を使っている
  • CRRによって、私達のインフラで見ている全てのヘッダーとリクエストにカスタムタグをつけることが可能
  • そして、このリクエストが私たちのサービスやマイクロサービスを通じて伝搬されると、このリクエストコンテキスト情報が渡され、そして、リクエストが個々の注入ポイントを通過すると、インジェクションポイントは常にヘッダーを検査し、その特定のリクエストに対してトリガーされるべき注入ポイントが何かを確認することができる
• 当社のソフトウェア・エンジニアなら誰でも、失敗を注入する場所や使用するシナリオを作成したり選択したりできるUIがあり、さらに自分のデバイスで直接カオスエンジニアリングテストを行うことができる。それが「FIT」
  • Netflixのエンジニアは史上始めて、カオスエンジニアやレジリエンスの助けを借りることなく、カオスの実験を行うことができる

カナリアを使ったアプローチ

• 同じ頃、別のアプローチでの技術を作られていた
• デプロイのリスクを回避するために、２つのクラスタを使いカナリアを使って標準に戻すというアプローチをとった
• この２つのクラスタがお互いにどのような挙動をするかを観察する
• なので、このFITテクノロジーと、カナリアアプローチの２つの技術を組み合わせることにしたのは自然なことだった
• カナリア実験用のクラスタにFITセッションをつくる、そうすると、カナリアクラスタにしか影響を受けずにカオスエンジニアリングが可能

システムメトリクスを監視

• アトラスモニタリングシステムにより、Netflixのバックエンドサービスのシステムメトリクスを監視してきた
• しかし、よりメンバー体験にフォーカスした別のモニタリングも構築した
• イベントベースのモニタリングシステム
  • デバイスとファーストチームのサービスから来るすべてのイベントを収集
  • ユーザー割り当てアルゴリズムにより実験中のデバイスから来るイベントだけを収集可能
  • それらをフィルタリングして、ElasticSearchにプッシュし、あとでデバッグ可能な状態にする

カオスエンジニアリング導入の旅

• 私達は長年にわたって様々な実験をデザインしてきた
• 重要なのは、treatment、allocation、scopeの３つで、これらを組み合わせて使うことができる
• もしこれらのエンジニアリングをあなたの組織で導入するには長い旅になるかもしれないが、取るべきステップは次のようなものがある

Chaos Monkey

• 個々のノードが停止することで影響を受けると感じたら、オープンソースのChaos Monkeyを使うこともできるし、自分でノードをkillすることもできる
• Kubernetes上で動作することですでにノードの障害に強くなっている可能性もある
• AWS Fault Injection Simulator使えば、この種の障害をシミュレートすることも可能

Canaries

• カナリアはそれ自体が非常に優れた技術であり、すぐに恩恵を受けることができる
• spinnakerやkayentaはオープンソースなので使用可能
• 開発またはデプロイのワークフローのパイプラインにカナリアがあるようなリリースサイクルに移行することは、組織の大きな進化につながる

Tracing

• トレースも重要で興味深い技術
• Zipkinなどを使うなどで、カスタムヘッダーを付けることができる

Fault Injection

• Netflixが始めて構築された10年前と比べると、業界としてはるかに有利な状況にある
• サービスメッシュの進化に伴い、Envoyはすでに基本的な障害注入技術に対応している

今日話したインフラの実験は、私達ソフトウェアエンジニアができるだけ早くイノベーションを起こせるように、またNetflixの安全性と安定性を損なわないように、という一つの目的のもとに存在している。

私達が世界を楽しませたいと考えていることは周知の事実であり、これを達成するには全てのシステムがお互いにシームレスに調和して動作することが必要。

そしてお客様の喜びの瞬間をお届けすることですべてがうまくいく。

まとめ

Netflixがサービスの安定性のために培ってきたノウハウとそのターニングポイントについて、その10数年を追体験できたような、濃密なセッションでした。

カオスエンジニアリングについてはそこまで深く知っていたわけではなかったので、ツール類の紹介などもとても勉強になりました。

そして、またしても失敗から学びとることの大切さですね。暫定対策だけではなく、根本的にどうすれば再現できるのか、テストできるのかというところを突き詰めなければ、FITのようなツールの開発という発想にはなかなか至らないと思います。

エンジニア魂に感服しました。